Firefox 135 adds Idempotency-Key HTTP header behind pref
#28219
Conversation
github-actions
bot
added
data:http
|
Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs). |
You'll need to suggest this spec in the browser-specs repo. |
caugner
changed the title
Idempotency-Key HTTP header behind pref
|
Thanks @caugner - I've accepted this as non-standard and will add the spec back if w3c/browser-specs#2199 gets approved. |
hamishwillee
force-pushed
the
f145idempotentcy
branch
from
be64288 to
2887e0c
Compare
|
@caugner Don't know when BCD "finds" spec updates, but the spec for this was accepted in w3c/browser-specs#2199 - and I have added the spec-url and set this back to standard. Ready for your review. |
Should be fine with #28306 now. |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Thanks very much @caugner |
2 participants
FF135 added support for the
Idempotency-Keyheader in https://bugzilla.mozilla.org/show_bug.cgi?id=1830022 behind the preferencenetwork.http.idempotencyKey.enabled.There was an attempt to ship in 145 in https://bugzilla.mozilla.org/show_bug.cgi?id=1991641 but this has been withdrawn
This has a spec https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/ but adding it results in an error.
The key is sent in requests to indicate that a POST/PATCH is a particular unique command. If the server gets the same request with the same key it ignores it.
As specified the server defines the requirements for the key, which would be expected therefore to be unknown to the browser, and set by Javascript.
As such you wouldn't expect a browser integration, and hence no BCD entry.
However FF automatically attaches a key if one is not attached. This is non standard. But it does mean that the browser does something, so there is an integration and compatibility story.
Related docs work can be tracked in mdn/content#41497